home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0281.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  3.5 KB  |  70 lines
  1. > The arguments that in-band designation of document format is better
  2. > than out-of-band information may apply in the electronic mail
  3. > scenarios, where there is a single sender, multiple recipients, and
  4. > the recipient has no control over what the sender might send.
  5.  
  6. The argument is identical for most file servers, which have even less control
  7. over the specifics of what files they offer for retrieval. File servers usually
  8. rely on contributed material and only rarely have anything resembling precise
  9. control over the material they offer.
  10.  
  11. > Instead, imagine, if you would, another scenario, of a WAIS or Web or
  12. > anonymous FTP archive, which wishes to make available the latest
  13. > version of the MIME specification. Let us suppose, in addition, that
  14. > the publishing service has three different representations of the
  15. > document, one marked "MIME rich-text", one marked "postscript", and
  16. > one NetFax.  Furthermore, let us suppose (as has been proposed) that
  17. > the document types are marked by their MIME Content-type header
  18. > designation.
  19.  
  20. Nothing wrong with this.
  21.  
  22. > If I wish to retrieve the document, say to view it, I might want to
  23. > choose the available representation that is most appropriate for my
  24. > purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
  25. > from an anonymous FTP archive, only to discover that it is in the
  26. > newly announced Postscript level 4 format, or to try to edit it only
  27. > to discover that it is in the (upwardly compatible but not parsable by
  28. > my client) version 44 of Rich Text. In each case, the appropriateness
  29. > of alternate sources and representations of a document would depend on
  30. > information that is currently only available in-band.
  31.  
  32. Even if this happens (I have strong doubts that it will since documents made
  33. available for public retrieval tend to converge rapidly to lowest-common
  34. denominator usage) you have failed to propose an alternative that solves this
  35. usefully.
  36.  
  37. > I believe that MIME was developed in the context of electronic mail,
  38. > but that the usage patterns in space and time of archives, database
  39. > services and the like require more careful attention (a) to
  40. > out-of-band information about format versions, so that you might know,
  41. > before you retrieve a representation, whether you have the capability
  42. > of coping with it, and (b) some restriction on those formats which
  43. > might otherwise be uncontrollable.
  44.  
  45. And I disagree. You still have failed to explain how to overcome any of my
  46. objections to this approach.
  47.  
  48. > Finally, as much as I've tried to resist, I'll characterize your
  49. > description of my response as 'repeated failure on your part to read
  50. > the words I was writing' as 'inflammatory hogwash'.
  51.  
  52. Well, you're doing it again. You have failed to explain you intend to overcome
  53. any of the obstacles I've pointed out, precisely as if you have not bothered to
  54. read any of my previous response. Since one of them is the halting problem in
  55. disguise your method of overcoming it (assuming you have one) will be the
  56. computing news of the century.
  57.  
  58. I have no intention of answering any further mail from you until you come
  59. to grips with the objections I have laid out for about the tenth time.
  60.  
  61. Finally, let me point out that I speak as one of the maintainers of one of the
  62. largest archive of TeX material available anywhere. This material has been
  63. available via MIME-compliant mail server (and of course FTP) for over six
  64. months now. This archive contains hundreds of PostScript documents as well
  65. as all sorts of other stuff. The problems you seem to think are endemic to
  66. this sort of services have yet to materialize.
  67.  
  68.                 Ned
  69.  
  70.